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Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


This memo updates RFC 4733 to add event codes for telephony signals 
used for channel-associated signalling when carried in the telephony 
event RTP payload. It supersedes and adds to the original assignment 
of event codes for this purpose in Section 3.14 of RFC 2833. As 
documented in Appendix A of RFC 4733, some of the RFC 2833 events 
have been deprecated because their specification was ambiguous, 
erroneous, or redundant. In fact, the degree of change from Section 
3.14 of RFC 2833 is such that implementations of the present document 
will be fully backward compatible with RFC 2833 implementations only 
in the case of full ABCD-bit signalling. This document expands and 
improves the coverage of signalling systems compared to RFC 2833. 
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Introduction 

Overview 


This document extends the set of telephony events defined within the 
framework of RFC 4733 [4] to include signalling events that can 
appear on a circuit in the telephone network. Most of these events 
correspond to signals within one of several channel-associated 
Signalling systems still in use in the PSTN. 


Trunks (or circuits) in the PSTN are the media paths between 
telephone switches. A succession of protocols have been developed 
using tones and electrical conditions on individual trunks to set up 
telephone calls using them. The events defined in this document 
support an application where such PSTN signalling is carried between 
two gateways without being signalled in the IP network: the "RTP 
trunk" application. 


In the "RTP trunk" application, RTP is used to replace a normal 
circuit-switched trunk between two nodes. This is particularly of 
interest in a telephone network that is still mostly 
circuit-switched. In this case, each end of the RTP trunk encodes 
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audio channels into the appropriate encoding, such as G.723.1 [13] or 
G.729 [14]. However, this encoding process destroys in-band 
signalling information that is carried using the least-significant 
bit ("robbed bit signalling") and may also interfere with in-band 
signalling tones, such as the MF (multi-frequency) digit tones. 


In a typical application, the gateways may exchange roles from one 
call to the next: they must be capable of either sending or receiving 
each implemented signal in Table 1. 


This document defines events related to four different signalling 
systems. Three of these are based on the exchange of multi-frequency 
tones. The fourth operates on digital trunks only, and makes use of 
low-order bits stolen from the encoded media. In addition, this 
document defines tone events for supporting tasks such as continuity 
testing of the media path. 


Implementors are warned that the descriptions of signalling 
systems given below are incomplete. They are provided to give 
context to the related event definitions, but omit many details 
important to implementation. 


1.2. Terminology 


In this document, the key words "MUST", "MUST NOT", "REQUIRED", 
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 
and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 
indicate requirement levels for compliant implementations. 


In addition to the abbreviations defined below for specific events, 
this document uses the following abbreviations: 


KP Key Pulse 

MF Multi-frequency 

PSTN Public Switched (circuit) Telephone Network 
RTP Real-time Transport Protocol [2] 


ST Start 
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26 


Event Definitions 


Table 1 lists all of the events defined in this document. As 
indicated in Table 8 (Appendix A) of RFC 4733 [4], use of some of the 
RFC 2833 [11] event codes has been deprecated because their 
specification was ambiguous, erroneous, or redundant. In fact, the 
degree of change from Section 3.14 of RFC 2833 is such that 
implementations of the present document will be fully backward 
compatible with RFC 2833 implementations only in the case of full 
ABCD-bit signalling. This document expands and improves the coverage 
of signalling systems compared to RFC 2833. 


Note that the IANA registry for telephony event codes was set up by 
RFC 4733, not by RFC 2833. Thus, event code assignments originally 
made in RFC 2833 appear in the registry only if reaffirmed in RFC 
4733 or an update to RFC 4733, such as the present document. 
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+--------------------- +------------ +------------- +-------- +--------- + 
| Event | Frequency | Event Code | Event | Volume? | 
| | (Hz) | | Type | | 
+--------------------- +------------ +------------- +-------- +--------- + 
| MF 0...9 | (Table 2) | 128...137 | tone | yes | 
| | | | | | 
| MF Code 11 (SS No. | 700+1700 | 123 | tone | yes 
| 5) or KP3P/ST3P | | | | | 
liaa | | | | | 
| MF KP (SS No. 5) or | 110041700 | 124 | tone | yes | 
ee a uz toc lan | 
| MF KP2 (SS No. 5) | 1300+1700 | 125 | tone | yes | 
| or KP2P/ST2P (R1) | | | | | 
| MF ST (SS No. 5 and | 1500+1700 | 126 | tone | yes | 
| R1) | | | | | 
| | | | | | 
| MF Code 12 (SS No. | 900+1700 | 127 | tone | yes 
| 5) or KP’/STP (R1) | | | | | 
| ABCD signalling | N/A | 144...159 | state | no 
| | | | | | 
| AB signalling (C, D | N/A | 208...211 | state | no | 
| unused) | | | | | 
A bit signalling N/A 206...207 state no 
(B, C, D unused) 
| | | | | | 
| Continuity | 2000 | 121 | tone | yes 
| check-tone | | | | | 
| | | | | | 
Continuity 1780 122 tone yes 
verify-tone 
| | | | | | 
| Metering pulse | N/A | 174 | other | no 
| | | | | | 
| Trunk unavailable ű | N/A | 175 | other | no 
| MFC Forward 1...15 | (Table 4) | 176...190 | tone | yes | 
| | | | | | 
| MFC Backward 1...15 | (Table 5) | 191...205 | tone | yes | 
+--------------------- +------------ +------------- +-------- +--------- + 


Table 1: Trunk Signalling Events 


Schulzrinne & Taylor Standards Track [Page 5] 


RFC 5244 Channel-Oriented Signalling Events June 2008 


2.1. Signalling System No. 5 


Signalling System No. 5 (SS No. 5) is defined in ITU-T 
Recommendations 9.140 through 9.180 [5]. It has two systems of 
signals: "line" signalling to acquire and release the trunk, and 
"register" signalling to pass digits forward from one switch to the 
next. 


2.1.1. Signalling System No. 5 Line Signals 


No. 5 line signalling uses tones at two frequencies: 2400 and 2600 
Hz. The tones are used singly for most signals, but together for the 
Clear-forward and Release-guard. (This reduces the chance of an 
accidental call release due to carried media content duplicating one 
of the frequencies.) The specific signal indicated by a tone depends 
on the stage of call set-up at which it is applied. 


No events are defined in support of No. 5 line signalling. However, 
implementations MAY use the AB bit events described in Section 2.4 
and shown in Table 1 to propagate SS No. 5 line signals. If they do 
so, they MUST use the following mappings. These mappings are based 
on an underlying mapping equating A=0 to presence of 2400 Hz signal 
and B=0 to presence of 2600 Hz signal in the indicated direction. 


o both 2400 and 2600 Hz present: event code 208; 
o 2400 Hz present: event code 210; 

o 2600 Hz present: event code 209; 

o neither signal present: event code 211. 


The initial event report for each signal SHOULD be generated as soon 
as the signal is recognized, and in any case no later than the time 
of recognition as indicated in ITU-T Recommendation 9.141, Table 1 
(i.e., 40 ms for "Seizing" and "proceed-to-send", 125 ms for all 
other signals). The packetization interval following the initial 
report SHOULD be chosen with considerations of reliable transmission 
given first priority. Note that the receiver must supply its own 
volume values for converting these events back to tones. Moreover, 
the receiver MAY extend the playout of "Seizing" until it has 
received the first report of a KP event (see below), so that it has 
better control of the interval between ending of the seizing signal 
and start of KP playout. 


The KP has to be sent beginning 80 +/- 20 ms after the SS No. 5 
"seizing" signal has stopped. 
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2.1.2. Signalling System No. 5 Register Signals 


No. 5 register signalling uses pairs of tones to convey digits and 
signals framing them. The tone combinations and corresponding 
signals are shown in the Table 2. All signals except KP1 and KP2 are 
sent for a duration of 55 ms. KP1 and KP2 are sent for a duration of 
100 ms. Inter-signal pauses are always 55 ms. 


Upper Frequency (Hz) 


+----------------- +--------- +--------- +--------- +--------- +--------- + 
| Lower Frequency | 900 | 1100 | 1300 | 1500 | 1700 | 
| (Hz) | | | | | | 
+----------------- +--------- +--------—- +--------—- +--------- +--------- + 
| 700 | Digit 1 | Digit 2 | Digit 4 | Digit 7 | Code 11 | 
| 900 | | Digit 3 | Digit 5 | Digit 8 | Code 12 | 
| | | | | | | 
| 1100 | | | Digit 6 | Digit 9 | KP1 | 
| | | | | | | 
| 1300 | | | | Digit 0 | KP2 | 
1500 ST 
+----------------- +--------—- +--------- +--------—- +--------—- +--------- + 


Table 2: SS No. 5 Register Signals 


The KP signals are used to indicate the start of digit signalling. 
KP1 indicates a call expected to terminate in a national network 
served by the switch to which the signalling is being sent. KP2 
indicates a call that is expected to transit through the switch to 
which the signalling is being sent, to another international 
exchange. The end of digit signalling is indicated by the ST signal. 
Code 11 or Code 12 following a country code (and possibly another 
digit) indicates a call to be directed to an operator position in the 
destination country. A Code 12 may be followed by other digits 
indicating a particular operator to whom the call is to be directed. 


Implementations using the telephone-events payload to carry SS No. 5 
register signalling MUST use the following events from Table 1 to 
convey the register signals shown in Table 2: 

o event code 128 to convey Digit 0; 


o event codes 129-137 to convey Digits 1 through 9, respectively; 


o event code 123 to convey Code 11; 
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o event code 124 to convey KP1; 

o event code 125 to convey KP2; 

o event code 126 to convey ST; 

o event code 127 to convey Code 12. 


The sending implementation SHOULD send an initial event report for 
the KP signals as soon as they are recognized, and it MUST send an 
event report for all of these signals as soon as they have completed. 


2.2. Signalling System R1 and North American MF 


Signalling System R1 is mainly used in North America, as is the more 
common variant designated simply as "MF". Rl is defined in ITU-T 
Recommendations Q.310-0.332 [6], while MF is defined in [9]. 


Like SS No. 5, R1/MF has both line and register signals. The line 
signals (not counting Busy and Reorder) are implemented on analog 
trunks through the application of a 2600 Hz tone, and on digital 
trunks by using ABCD signalling. Interpretation of the line signals 
is state-dependent (as with SS No. 5). 


2.2.1. Signalling System R1 Line Signals 


In accordance with Table 1/Q.311, implementations MAY use the A bit 
events described in Section 2.4 and shown in Table 1 to propagate R1 
line signals. If they do so, they MUST use the following mappings. 
These mappings are based on an underlying mapping equating A=0 to the 
presence of a 2600 Hz signal in the indicated direction and A=1 to 
the absence of that signal. 


o 2600 Hz present: event code 206; 
o no signal present: event code 207. 

2.2.2. Signalling System R1 Register Signals 
Rl has a signal capacity of 15 codes for forward inter-register 
signals but no backward inter-register signals. Each code or digit 
is transmitted by a tone pair from a set of 6 frequencies. The R1 


register signals consist of KP, ST, and the digits "0" through "9". 
The frequencies allotted to the signals are shown in Table 3. Note 
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that these frequencies are the same as those allotted to the 
similarly named SS No. 5 register signals, except that KP uses the 
frequency combination corresponding to KP1 in SS No. 5. Table 3 also 
shows additional signals used in North American practice: KP’, KP2P, 
KP3P, STP or ST’, ST2P, and ST3P [9]. 


Upper Frequency (Hz) 


+------------ +--------- +--------- +--------- +--------- +-------------- + 
| Lower | 900 | 1100 | 1300 | 1500 | 1700 | 
| Frequency | | | | | | 
| (Hz) | | | | | | 
+------------ +--------- +--------- +--------- +--------- +-------------- + 
| 700 | Digit 1 | Digit 2 | Digit 4 | Digit 7 | KP3P or ST3P | 
| | | | | | | 
900 | | Digit 3 | Digit 5 | Digit 8 | KP’ or STP 
| 1100 | | | Digit 6 | Digit 9 | KP | 
| | | | | | | 
| 1300 | | | | Digit 0 | KP2P or ST2P | 
| | | | | | | 
| 1500 | | | | | ST | 
4+------------ 4+--------- +--------- +--------- +--------- +-------------- + 


Table 3: R1/MF Register Signals 

Implementations using the telephone-events payload to carry North 
American R1 register signalling MUST use the following events from 
Table 1 to convey the register signals shown in Table 3: 
o event code 128 to convey Digit 0; 
o event codes 129-137 to convey Digits 1 through 9, respectively; 
o event code 123 to convey KP3P or ST3P; 
o event code 124 to convey KP; 
o event code 125 to convey KP2P or ST2P; 
o event code 126 to convey ST; 
o event code 127 to convey KP’ or STP. 

As with the original telephony signals, the receiver interprets 


codes 123, 125, and 127 as KPx or STx signals based on their 
position in the signalling sequence. 
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Unlike SS No. 5, R1 allows a large tolerance for the time of onset of 
register signalling following the recognition of start-dialling line 
signal. This means that sending implementations MAY wait to send a 
KP event report until the KP has completed. 


2.3. Signalling System R2 


The International Signalling System R2 is described in ITU-T 
Recommendations Q.400-0.490 [7], but there are many national 
variants. R2 line signals are continuous, out-of-band, link by link, 
and channel associated. R2 (inter)register signals are multi- 
frequency, compelled, in-band, end-to-end, and also channel 
associated. 


2.3.1. Signalling System R2 Line Signals 


R2 line signals may be analog, one-bit digital using the A bit in the 
16th channel, or digital using both A and B bits. Implementations 
MAY use the A bit or AB bit events described in Section 2.4 and shown 
in Table 1 to propagate these signals. If they do so, they MUST use 
the following mappings. 


1. For the analog R2 line signals shown in Table 1 of ITU-T 
Recommendation Q.411, implementations MUST map as follows. This 
mapping is based on an underlying mapping of A bit = 0 when tone 
is present. 


* event code 206 (Table 1) is used to indicate the Q.411 "tone- 
on" condition; 


* event code 207 (Table 1), is used to indicate the Q.411 "tone- 
off" condition. 


2. The digital R2 line signals, as described by ITU-T Recommendation 
Q.421, are carried in two bits, A and B. The mapping between A 
and B bit values and event codes SHALL be the same in both 
directions and SHALL follow the principles for A and B bit 
mapping specified in Section 2.4. 


2.3.2. Signalling System R2 Register Signals 


In R2 signalling, the signalling sequence is initiated from the 
outgoing exchange by sending a line "Seizing" signal. After the line 
"Seizing" signal (and "seizing acknowledgment" signal in R2D), the 
signalling sequence continues using MF register signals. ITU-T 
Recommendation Q.441 classifies the forward MF register signals 
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(upper frequencies) into Groups I and II, the backward MF register 
signals (lower frequencies) into Groups A and B. These groups are 
significant with respect both to what sort of information they convey 
and where they can occur in the signalling sequence. 


The tones used in R2 register signalling are combinations of two out 
of six frequencies. National versions may be reduced to 10 signals 
(two out of five frequencies) or 6 signals (two out of four 
frequencies). 


R2 register signalling is a compelled tone signalling protocol, 
meaning that one tone is played until an "acknowledgment or directive 
for the next tone" is received that indicates that the original tone 
should cease. A R2 forward register signal is acknowledged by a 
backward signal. A backward signal is acknowledged by the end of the 
forward signal. In exceptional circumstances specified in ITU-T Rec. 
Q.442, the downstream entity may send backward signals autonomously 
rather than in response to specific forward signals. 


In R2 signalling, the signalling sequence is initiated from the 
outgoing exchange by sending a forward Group I signal. The first 
forward signal is typically the first digit of the called number. 
The incoming exchange typically replies with a backward Group A-1 
indicating to the outgoing exchange to send the next digit of the 
called number. 


The tones have meaning; however, the meaning varies depending on 
where the tone occurs in the signalling. The meaning may also depend 
on the country. Thus, to avoid an unmanageable number of events, 
this document simply provides means to indicate the 15 forward and 15 
backward MF R2 tones (i.e., using event codes 176-190 and 191-205, 
respectively, as shown in Table 1). The frequency pairs for these 
tones are shown in Table 4 and Table 5. 


Note that a naive strategy for onward relay of R2 inter-register 
signals may result in unacceptably long call setup times and timeouts 
when the call passes through several exchanges as well as a gateway 
before terminating. Several strategies are available for speeding up 
the transfer of signalling information across a given relay point. 

In the worst case, the relay point has to act as an exchange, 
terminating the signalling on one side and reoriginating the call on 
the other. 
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Upper Frequency (Hz) 


+---------------------- +------- +------- +------- +-------- 
| Lower Frequency (Hz) | 1500 | 1620 | 1740 | 1860 
+---------------------- +------- +------- +------- +-------- 
| 1380 | Fwd 1 | Fwd 2 | Fwd 4 | Fwd 7 
| | | | | 
| 1500 | | Fwd 3 | Fwd 5 | Fwd 8 
1620 | | | Fwd 6 | Fwd 9 
| | | | | 
| 1740 | | | | Fwd 10 
| | | | | 
| 1860 | | | | 
+---------------------- +------- +------- +------- +-------- 
Table 4: R2 Forward Register Signals 
Upper Frequency (Hz) 
+----------------- +--------- +--------- +--------- +-------- 
Lower Frequency 1140 1020 900 780 
(Hz) 
+----------------- 4+--------- +--------- +--------- +-------- 
| 1020 | Bkwd 1 | | | 
| | | | | 
| 900 | Bkwd 2 | Bkwd 3 | 
| 780 | Bkwd 4 | Bkwd 5 | Bkwd 6 | 
| | | | | 
| 660 | Bkwd 7 | Bkwd 8 | Bkwd 9 | Bkwd 10 
| | | | | 
| 540 | Bkwd 11 | Bkwd 12 | Bkwd 13 | Bkwd 14 
+----------------- +--------- +--------—- +--------- +--------- 


Table 5: R2 Backward Register Signals 


2.4. ABCD Transitional Signalling for Digital Trunks 


+ 


+ ——— c H 


June 2008 


ABCD is a 4-bit signalling system used by digital trunks, where A, B, 


C, and D are the designations of the individual bits. 


Signalling may 


be 16-state (all four bits used), 4-state (A and B bits used), or 
2-state (A-bit only used). ABCD signalling events are all mutually 
exclusive states. The most recent state transition determines the 


current state. 
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When using Extended Super Frame (ESF) T1 framing, signalling 
information is sent as robbed bits in frames 6, 12, 18, and 24. A D4 
superframe only transmits 4-state signalling with A and B bits. On 
the Conference of European Postal and Telecommunications (CEPT) El 
frame, all signalling is carried in timeslot 16, and two channels of 
16-state (ABCD) signalling are sent per frame. ITU-T Recommendation 
G.704 [10] gives the details of ABCD bit placement within the various 
framing arrangements. 


The meaning of ABCD signals varies with the application. One example 
of a specification of ABCD signalling codes is T1.403.02 [16], which 
reflects North American practice for "loop" signalling as opposed to 
the trunk signalling discussed in previous sections. 


Since ABCD information is a state rather than a changing signal, 
implementations SHOULD use the following triple-redundancy mechanism, 
similar to the one specified in ITU-T Rec. 1.366.2 [15], Annex L. At 
the time of a transition, the same ABCD information is sent 3 times 
at an interval of 5 ms. If another transition occurs during this 
time, then this continues. After a period of no change, the ABCD 
information is sent every 5 seconds. 


As shown in Table 1, the 16 possible states are represented by event 
codes 144 to 159, respectively. Implementations using these event 
codes MUST map them to and from the ABCD information based on the 
following principles: 


1. State numbers are derived from the used subset of ABCD bits by 
treating them as a single binary number, where the A bit is the 
high-order bit. 

2. State numbers map to event codes by order of increasing value 
(i.e., state number 0 maps to event code 144, ..., state number 


15 maps to event code 159). 


If only the A and B bits are being used, then the mapping to event 
codes shall be as follows: 


o A=0, B=0 maps to event code 208; 
o A=0, B=1 maps to event code 209; 


o A=1, B=0 maps to event code 210; 


o A=1, B=1 maps to event code 211; 
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Finally, if only the A bit is used, 


o A 0 maps to event code 206; 


o A= 1 maps to event code 207; 


Separate event codes are assigned to A-bit and AB-bit signalling 
because, as indicated in Rec. G.704 [10], when the B, C, and D 
bits are unused, their default values differ between transmission 
systems. By specifying codes for only the used bits, this memo 
allows the receiving gateway to fill in the remaining bits 
according to local configuration. 


2.5. Continuity Tones 


Continuity tones are used for testing circuit continuity during call 
setup. Two basic procedures are used. In international practice, 
clause 7 of ITU-T Recommendation Q.724 [8] describes a procedure 
applicable to four-wire trunk circuits, where a single 2000 +/- 20 Hz 
check-tone is transmitted from the initiating telephone switch. The 
remote switch sets up a loopback, and the continuity check passes if 
the sending switch can detect the tone on the return path. Clause 8 
of Q.724 describes the procedure for two-wire trunk circuits. The 
two-wire procedure involves two tones: a 2000 Hz tone sent in the 
forward direction and a 1780 +/- 20 Hz tone sent in response. 


Note that implementations often send a slightly different check-tone, 
e.g., 2010 Hz, because of undesirable aliasing properties of 2000 Hz. 


If implementations use the telephone-events payload type to propagate 
continuity check-tones, they MUST map these tones to event codes as 
follows: 


o For four-wire continuity testing, the 2000 Hz check-tone is mapped 
to event code 121. 


o For two-wire continuity testing, the initial 2000 Hz check-tone Hz 
tone is mapped to event code 121. The 1780 Hz continuity 
verify-tone is mapped to event code 122. 


2.6. Trunk Unavailable Event 
This event indicates that the trunk is unavailable for service. The 
length of the downtime is indicated in the duration field. The 


duration field is set to a value that allows adequate granularity in 
describing downtime. A value of 1 second is RECOMMENDED. When the 
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trunk becomes unavailable, this event is sent with the same timestamp 
three times at an interval of 20 ms. If the trunk persists in the 
unavailable state at the end of the indicated duration, then the 
event is retransmitted, preferably with the same redundancy scheme. 


Unavailability of the trunk might result from a failure or an 


administrative action. This event is used in a stateless manner to 
synchronize trunk unavailability between equipment connected through 
provisioned RTP trunks. It avoids the unnecessary consumption of 


bandwidth in sending a continuous stream of RTP packets with a fixed 
payload for the duration of the downtime, as would be required in 
certain El-based applications. In Tl-based applications, trunk 
conditioning via the ABCD transitional events can be used instead. 


2.7. Metering Pulse Event 


The metering pulse event may be used to transmit meter pulsing for 
billing purposes. For background information, one possible reference 
is http://www.seg.co.uk/telecomm/automat3.htm. Since the metering 
pulse is a discrete event, each metering pulse event report MUST have 
both the ’M’ and ’E’ bits set. Meter pulsing is normally transmitted 
by out-of-band means while conversation is in progress. Senders MUST 
therefore be prepared to transmit both the telephone-event and audio 
payload types simultaneously. Metering pulse events MUST be 
retransmitted as recommended in Section 2.5.1.4 of RFC 4733 [4]. It 
is RECOMMENDED that the retransmission interval be the lesser of 50 
ms and the pulsing rate but no less than audio packetization rate. 


3. Congestion Considerations 


The ability to adapt to congestion varies with the signalling system 
being used and also differs between line and register signals. 


With the specific exception of register signalling for S.S. No. 5 and 
R1/MF, the signals described in this document are fairly tolerant of 
lengthened durations, should these be necessary. Thus in congested 
conditions, the sender may adapt by lengthening the reporting 
interval for the tones concerned. At the receiving end, if a tone is 
being played out and an under-run occurs due to delayed or lost 
packets, it is best to continue playing the tone until the next 
packet arrives. Interrupting a tone prematurely, with or without 
resumption, can cause the call setup attempt to fail, whereas 
extended playout just increases the call setup time. 


Register signalling for S.S. No. 5 and R1/MF is subject to time 
constraints. Both the tone signals and the silent periods between 
them have specified durations and tolerances of the order of 5 to 10 
ms. The durations of the individual tones are of the order of two to 
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three packetization intervals (55/68 ms, with the initial KP lasting 


100 ms). The critical requirement for transmission of the 
telephony-event payload is that the receiver knows which signal to 
play out at a given moment. It is less important that the receiver 


receive timely notification of the end of each tone. Rather, it 
should play out the sequence with the durations specified by the 
Signalling standard instead of the actual durations reported. 


These considerations suggest that as soon as a register signal has 
been reliably identified, the sender should emit a report of that 
tone. It should then provide an update within 5 ms for reliability 
and no more updates until reporting the end of the tone. 


Increasing the playout buffer at the receiver during register 
Signalling will increase reliability. This has to be weighed against 
the implied increase in call setup time. 


4. Security Considerations 


The events for which event codes are provided in this document relate 
directly to the setup, billing, and takedown of telephone calls. As 
such, they are subject, using the terminology of RFC 3552 [12], to 
threats to both communications and system security. The attacks of 
concern are: 


o confidentiality violations (monitoring of calling and called 
numbers); 


o establishment of unauthorized telephone connections through 
message insertion; 


o hijacking of telephone connections through message insertion or 
man-in-the-middle modification of messages; 


o denial of service to individual telephone calls through message 
insertion, modification, deletion, or delay. 


These attacks can be prevented by the use of appropriate 
confidentiality, authentication, or integrity protection. If 
confidentiality, authentication, or integrity protection are needed, 
then Secure Real-time Transport Protocol (SRTP) [3] SHOULD be used 
with automated key management. 


Additional security considerations are described in RFC 4733 [4]. 
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5. IANA Considerations 


This document defines the event codes shown in Table 6. 


[4]. 
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| Event Code 
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12:3 


124 


146 
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| 
| 


Continuity check-tone 


Continuity verify-tone 


SS 


Code 11 (SS No. 5) or KP3P/ST3P 
KP (SS No. 5) or KP1 (R1) 
KP2 (SS No. 5) or KP2P/ST2P (R1) 
ST (SS No. 5 and R1) 
Code 12 (SS No. 5) or KP’/STP (R1) 
No. 5 or RI digit "0" 
No. 5 or RI digit "1" 
No. 5 or R1 digit "2" 
No. 5 or RI digit "3" 
No. 5 or RI digit "4" 
No. 5 or RI digit "5" 
No. 5 or RI digit "6" 
No. 5 or R1 digit "7" 
No. 5 or RI digit "8" 
No. 5 or RI digit "9" 
ABCD signalling state ’0000’ 
ABCD signalling state ’0001’ 
ABCD signalling state ’0010’ 
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These events 
are additions to the telephone-event registry established by RFC 4733 


The reference for all of them is the present document. 
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A bit signalling state ’0’ 
A bit signalling state ’1’ 


AB bit signalling state ’00’ 
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| | | 
| AB bit signalling state ’01’ | [RFC5244] | 


N 
C 
Xe) 


210 AB bit signalling state ’10’ [RFC5244] 
| 211 | AB bit signalling state '11’ | [RFC5244] | 
+------------ +---------------------------- === --- === +----------- + 


Table 6: Channel-Oriented Signalling Events in the 
Audio/Telephone-Event Event Code Registry 
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